This can be removed

I hoped to fix the expect-error in the screen, kinda still want to keep this

LinearGradientProps has start & end props (link), I think the user should be able to control them.
Nice work with the angle prop but playing with start & end can give you more results (what I asked about if the gradient can start from another point)

Do you have an example where this is useful? More to the point, if we ever move to react-native-gradients - it supports angle and not start & end

example:

        <View width={80} height={80}>
          <LinearGradient
            colors={[Colors.$backgroundPrimaryHeavy, Colors.$backgroundPrimaryMedium, Colors.$backgroundPrimaryLight]}
            start={{x: 0.01, y: 0.02}}
            end={{x: 0.9, y: 0.8}}
          >
            <View width={80} height={80} center>
              <Text white>Hello</Text>
            </View>
          </LinearGradient>
        </View>

As you can see the gradient as more of the backgroundPrimaryLight since the start coordinates changed.

Does the react-native-gradients migration will be soon ?

Technically we can get something very similar using a different colors array (for example: const COLORS = [Colors.$backgroundPrimaryHeavy, Colors.$backgroundPrimaryMedium, Colors.$backgroundPrimaryMedium];)

Either way I don't want to add a general support for start and end, if it'll be required we can add a specific type for it (so we can deprecate it more easily).

Not sure we'll do it, it does't seem like it's very active, but it's only a few JS files, so we can more easily handle changes if we need to.

The center alignment props only affect the children content, not the gradient.
These should be moved to a separate prop group like ContentAlignmentProps with boolean values, WDYT ?

Doesn't center always affects the children?

it does, for me when I pass center or centerV/H to the gradient I expect the color of the gradient to be aligned also.
I leave it up to you.

I've changed the screen's text but I think the modifier is ok

This useEffect isn't relevant because the fallback is {default: () => null}, not undefined.
Am I missing something ?

You're right, I'm reverting the change to LinearGradientPackage since it affects SkeletonView as well

This if (!LinearGradient) check is irrelevant because LinearGradient cannot be falsy (it's either a component or a function).
The fallback function () => null will pass this check consider checking if (LinearGradient === null) instead.

Changed a little

This file includes changes that belong in a different PR.
Have you verified that these changes don't break other screens ?

The changes are required for this PR, if I made these changed in another (clean) PR, how would we test them?
Tested a few screens